The present invention relates to a computer system having a remote method invocation mechanism and, more particularly, to a stub search loading system and method in a computer system in which a stub necessary on the client side is downloaded from the server side and used.
RMI (Remove Method Invocation) is a mechanism capable of invoking the method of a Java object on another Java virtual machine as if it were the method of an object on a given Java virtual machine and is used to built a distributed system using Java.
FIG. 10 shows the outline of the RMI mechanism. The RMI is processed according to the following procedure. First, an invocation from a client object to a server object is sent to a stub placed in the client (S31). The stub executes marshaling or the like for this invocation and transfers it to a skeleton in the server (S32). The skeleton executes unmarshaling or the like for the invocation received from the stub to generate the invocation to the server object and invokes the server object (S33). Marshaling means processing of converting an internal data expression format into a data format exchangeable between different systems, and unmarshaling means reverse processing.
The server object executes the invoked method and, if a return value is present, sends it to the skeleton (S34). The skeleton executes marshaling or the like for the received return value and returns it to the stub in the client (S35). The stub executes unmarshaling or the like for the received return value and returns it to the invocation source client object as the return value of method invocation (S36).
In this way, all invocations from a client object to a server object are done through a stub. That is, a stub serves as an agent for a server object on a client side in a distributed environment. Generally, one stub is necessary for each server object.
A sub and skeleton can be generated by, using an IDL (Interface Definition Language) compiler, an IDL file in which a server application invocation interface is described. In actual use of a stub and skeleton, in compiling a client application and server application, the stub and skeleton are generally linked and compiled together (this scheme will be referred to as a static scheme hereinafter). In the static scheme, however, information necessary to invoke a remote method must be determined not at the time of program execution but at the time of compiling. If a stub linked to a program does not match a remote method invoked in executing the program, an error may occur, resulting in a decrease in efficiency. In addition, the storage capacity must be large enough to store all stubs on the client side.
To solve this problem, a scheme in which a client dynamically downloads a stub from a server and uses it has been proposed, as disclosed in Japanese Patent Laid-Open No. 10-83308 (this scheme will be referred to as a dynamic scheme hereinafter). A conventional dynamic scheme will be described below with reference to the accompanying drawings.
FIG. 11 shows a conventional computer system that employs a dynamic scheme. In this conventional computer system, client computers 101 and 102, a server computer 103, and a name server computer 104 are connected to each other through a network 105.
A Java runtime environment 110 is built in the client computer 101. Classes 111 are executed under the Java runtime environment 110. A Java runtime environment means software required to execute a Java program, including a Java virtual machine. Each class 111 is a class file created by compiling a Java source code and is described using a code to be executed by a Java virtual machine. Referring to FIG. 11, all classes in the client computer 101, including stub classes, are expressed by the classes 111.
The Java runtime environment 110 includes a control section 112, a class loader 114 having a stub search section 113, and instances 115. The stub search section 113 downloads a stub class from the server computer 103. The class loader 114 loads to the Java runtime environment 110 the class 111 and the stub class downloaded by the stub search section 113. The instances 115 are objects obtained by converting the classes 111 and stub classes loaded by the class loader 114 into instances. Referring to FIG. 11, all instances in the Java runtime environment 110, including stub class instances, are expressed by the instances 115.
Each instance (object) 115 has a variable (status) and method (behavior). As is known, in object-oriented programming, such a plurality of objects (instances) exchange messages, and a program is executed by the interaction between the objects. The control section 112 is the control module of the Java runtime environment 110 and includes a Java virtual machine. The control section 112 generates the instance 115 by converting each of the classes downloaded by the class loader 114 into an instance and controls program execution on the client side.
The other client computer 102 has the same arrangement as that of the client computer 101.
A Java runtime environment 120 is built in the server computer 103. Under the Java runtime environment 120, classes 121 and skeleton classes 122 are executed. The Java runtime environment 120 includes a control section 123, class loader 124, and instances 125. The class loader 124 loads the class 121 and skeleton class 122 to the Java runtime environment 120. The instances 125 are objects generated by converting the classes 121 and skeleton classes 122 loaded by the class loader 124 into instances. Referring to FIG. 11, all instances in the Java runtime environment 120, including skeleton class instances, are expressed by the instances 125.
The control section 123 is the control module of the Java runtime environment 120 and includes a Java virtual machine. The control section 123 generates the instance 125 by converting each of the classes and skeleton classes loaded by the class loader 124 into an instance and controls program execution on the server side.
The server computer 103 also has stub classes 126 and stub search interface 127. The stub classes 126 and skeleton classes 122 are in a one-to-one correspondence. That is, pairs of skeleton classes 122 and stub classes 126 generated by compiling IDL files are held and managed by the server computer 103. Each of these stub classes 126 can be searched for in accordance with the name of the stub class. Upon receiving a download request with a designated stub class name from the stub search section 113 in the client computer 101 or 102, the stub search interface 127 searches for the stub class 126 having the designated stub class name and returns it to the stub search section 113 of the request source.
When the client computer 101 or 102 does not know the server computer 103 from which a necessary stub class should be downloaded, i.e., when the client computer 101 or 102 does not know the server computer 103 which holds the necessary stub class, the name server computer 104 notifies the client computer 101 or 102 of the corresponding server computer 103. Typically, the name server computer 104 manages a table which holds, for each stub class name, the identifier of the server computer 103 that holds the stub class. Upon receiving an inquiry with a designated stub class name from the client computer 101 or 102, the name server computer 104 looks up the table and returns the identifier of the corresponding server computer 103.
The RMI processing procedure in the conventional computer system will be described next with reference to the flow chart shown in FIG. 12.
When remote method invocation is done from the instance 115 of a certain class 111 to invoke a certain method of a certain class 121 in the server computer 103, the control section 112 in the Java runtime environment 110 of the client computer 101 determines whether the instance 115 of the stub class 126 to be used for the invocation is present in the Java runtime environment 110 (S101). If YES in step S101, the remote method invocation is realized using the instance 115 of the stub class 126 in accordance with the procedure described with reference to FIG. 10 (S102).
If the instance 115 of the stub class 126 to be used for the current invocation is not present in the Java runtime environment 110, the control section 112 determines whether the stub class 126 to be used for the current invocation is present in the classes 111 in the client computer 101 (S103). If YES in step S103, the control section 112 causes the class loader 114 to load the class 111 of the stub class to be used for the current invocation to the Java runtime environment 110 (S104) and convert the class 111 into an instance, thereby generating the instance 115 of the stub class 126 to be used for the current invocation (S105). The remote method invocation is realized using the instance 115 of the stub class 126 (S102).
If the stub class 126 to be used for the current invocation is not present in the classes 111, it is determined whether the client computer 101 side knows the location of the stub class 126 to be used for the current invocation (S106). The location of the stub class 126 to be used for the current invocation can be included in, e.g., that invocation. Alternatively, the location of each stub class 126 can be managed by the class loader 114. In such case, the client computer 101 side knows the location of the stub class 126.
On the other hand, if the client computer 101 side does not know the location of the stub class 126 to be used for the current invocation, the control section 112 designates the class name of the stub class and inquires the name server computer 104 about it (S107). In response to this inquiry, the name server computer 104 notifies the client computer 101 of the location of the stub class having the designated class name (S108).
When the location of the stub class 126 to be used for the current invocation is known, the control section 112 causes the stub search section 113 to designate the class name and request the stub class of the server computer 103 uniquely determined by the location (S109). The stub search interface 127 in the server computer 103 searches for the stub class having the designated class name from the stub classes 126 and returns the stub class to the client computer 101 of the request source (S110 and S111). The returned stub class is loaded to the Java runtime environment 110 by the class loader 114 (S104), and the instance of the stub class is generated by the control section 112 (S105). The remote method invocation is realized using the instance 115 of the stub class 126 (S102).
If no corresponding stub class is found by search by the stub search interface 127, a message representing it is returned to the client computer 101 (S112). In this case, the stub class download request on the client computer 101 side fails, and the remote method invocation is ended as an error by exceptional processing.
A stub class is the class of a stub class instance for executing marshaling or the like and has a structure depending on the stub class runtime environment, which is specified by the machine, OS (Operating System), or Java runtime environment of the client computer where the stub class is to be executed. For this reason, if the type of the Java runtime environment 110 where the stub classes are executed changes, stub classes on the client side, which are necessary to invoke the methods of the instances 125 to be executed under the Java runtime environment 120 of the server computer 103, have different contents even when they have the same class name.
In the conventional computer system described with reference to FIG. 11, the stub search section 113 in the client computer 101 requests a stub class by designating a class name, and the stub search interface 127 in the server computer 103 returns a stub class having the designated class name. This procedure poses no problem if the client computers 101 and 102 use the Java runtime environments 110 of the same type. However, if the types of the Java runtime environments are different, only a client computer having a Java runtime environment adaptive to the stub class downloaded from the server computer 103 normally operates, though the normal operation cannot be guaranteed for the remaining client computers.
This means that since the types of Java runtime environments are difference, the plurality of client computers 101 and 102 which cannot use the same stub class cannot execute remote method invocation for the same server computer 103 by acquiring a stub by the dynamic scheme. This also means that a plurality of server computers must be prepared to allow a plurality of client computers, which cannot use the same stub class because of the difference in the type of the Java runtime environment, to execute remote method invocation.